【レポート】Amazon VPC の新機能と設計 #AWS-34 #AWSSummit
この記事では、5月12日に行われた AWS Summit Online 2021 のオンラインセッション『Amazon VPC の新機能と設計(AWS-34)』の模様をレポートします。
セッション概要
Amazon Virtual Private Cloud (Amazon VPC) で利用できる AWS PrivateLink の新機能や、新サービスである AWS Network Firewall、AWS Gateway Load Balancer を活用した設計について、ご紹介します。
登壇者
アマゾン ウェブ サービス ジャパン株式会社 レディネスソリューション本部 ソリューションアーキテクト ネットワークスペシャリスト 奥村 洋介
レポート
Agenda
- AWS PrivateLinkとアップデート
- 新サービス︓AWS Gateway Load Balancer
- 新サービス︓AWS Network Firewall
- AWS Transit Gatewayのアップデート
これまでのVPC関連のサービスについて
AWS PrivateLinkとアップデート
多く寄せられた課題
- S3などのVPC外のサービスを利用する際、インターネット経由のアクセスにしたくない
- あるVPCで展開しているサービスを別のVPCから利⽤したい場合、インターネット経由やVPCピアリングなどの接続設定が必要になる
- セキュリティポリシー上許容できない
- VPC CIDRの重複に気をつかう必要がある
上記の課題を解決するには、
インターフェースエンドポイント
- VPC内にAWSサービスのエンドポイントを作成し、プライベートアクセスを実現
- 現在はS3など92以上のサービスをサポート
エンドポイント サービス
- NLB配下のサービスをエンドポイントサービスとして異なるVPCに展開。IPアドレスの重複可能
- プライベートDNS名に対応
- きめ細かいIAMポリシーに対応
エンドポイントサービスの活用がよくわかる構成は以下。
Gateway Load Balancer (GWLB)
多く寄せられた課題
- VPCでファイアウォールやUTMなど、セキュリティアプライアンスを利⽤したいが、可⽤性の⾼いアーキテクチャをどう構成すれば良いか
- VPCでは、VRRPやHAなど、オンプレミスで利⽤していた冗⻑化⼿法が取れない
従来のセキュリティアプライアンスの冗⻑化⼿法
- 監視をトリガーとした API による切り替え
- EC2のアクティブ側ファイアウォール/パッシブ側ファイアウォールの冗長構成を構築。ルートテーブルで制御
- ↑は障害時のパッシブ側への切替の手法も作り込む必要がある
- VPN と BGPによる切り替え
- Transit VPCを作成し、そこにアクティブ側ファイアウォール/パッシブ側ファイアウォールを構築
- Peerダウンなどで自動切替を素早くできるが、構成が複雑でVPNのためVPC間の経路はインターネットとなる
- ELBサンドイッチ
- EC2のアクティブ側ファイアウォール/パッシブ側ファイアウォールを配置するサブネットを2つのELBで挟む構成(下のキャプチャ参照)
- 構築が大変、ELBを2つ利用するため費用も高くなる
上記の課題を解決するには、
Gateway Load Balancer
- 特徴
- 背後のアプライアンスを⽔平スケーリング
- 背後のアプライアンスにフォールトトレランス性を提供
- トラフィックを透過的に転送
- Firewall as a Serviceといったイメージでアプライアンス機能を提供可能
- 利⽤⽅法
- NLBと同様にアプライアンス群を設定
- サブネットのルートテーブルを設定してGWLBEにトラフィックを送信
- トラフィックフローについて
- 【例】インターネット→VPC Aのアプリケーションインスタンス
- まずingressルートテーブルより、GWLBEに転送される
- 次にアプライアンスインスタンスに向けて転送される
- その後GWLB経由でアプリケーションインスタンスにつながる
- アプリケーションインスタンスからインターネットは上記と真逆の順序でつながる
ローンチパートナーとプロバイダ
- Advanced security partners
- Analytics partners and providers
- Orchestration partners
- System integration partners
AWS NetworkFirewall
- VPCのサブネットに配置できるファイアウォールサービス
- GWLBがお好みのセキュリティアプライアンスを利⽤するのに対して、こちらはAWSマネージドのファイアウォールサービス
- 特徴
- トラフィックに応じて⾃動拡張
- 45Gbps超のスループット性能
- 冗⻑構成で99.99%のSLA
- ステートレス/ステートフルパケットフィルタ(5-tuple)
- ステートフルパケットフィルタ(ドメインリスト)、Suricata互換IPS
- 各種Log(flow log、イベントログ、ルール別のログ)をS3やCloudWatch Logs、Kinesis Firehoseへ格納
- CloudWatchルールメトリック
- AWS Firewall Managerによる⼀元管理
トラフィック検査フロー
- 最初にステートレスルールが評価される
- ステートレスルールにマッチしなかった場合、処理を選択可能
- ドロップする
- パスする
- ステートフルルールの評価に移⾏する
- ステートフルルールにマッチしなかった場合は、パスされる
AWS Network Firewall 構成例(GWLBでも同様)
AWS Transit Gateway
通信の対称性に関する課題
- インスタンス Aからインスタンス Bへのアクセスをセキュリティアプライアンス経由にする場合
- ⇨経路は「インスタンスA→TGW経由→AZ1のアプライアンス→TGW経由→インスタンスB」となる
- ⇨しかし戻りの通信経路は「インスタンスB→TGW経由→AZ2のアプライアンス→TGW経由→インスタンスA」となる
- →マルチAZ構成では、トラフィックフローが⾮対称になる可能性があり、セキュリティアプライアンスなどを利⽤する場合は都合が悪い
上記課題を解決する機能とは↓
AWS TRANSIT GATEWAY アプライアンスモード
- トラフィックフローが対称となり、正常な通信が可能
所感
本セッションは、Private Link、Gateway LoadBalancer、AWS Network Frewall、Transit Gatewayの4つの機能と活用方法はよくわかる内容でした。
オンプレミスとの接続設定では、規模が大きいほどルーティングの設定管理が手間となりますので、Network FirewallとTransitGatewayの機能はとても役に立ちます。
またGateway LoadBalancerの登場によって、Transit VPCのような構築や管理が大変な構成を作らなくてよくなったのはとてもありがたいです。
※通信経路の説明って文章にするより図を見せる方が一発で解るのでキャプチャ画面の貼り付けが多くなってしまいますね。